Over a period of time, use of software defined network (SDN) has increased. The reason behind the increase is the convenience with which such network can be managed. One example SDN 100 is shown in FIG. 1 (prior art). The SDN 100 includes a network management system (NMS) 102 for managing policies and other things in the SDN 100. The SDN 100 also includes a management software 104 for managing network in conjunction with the NMS 102. The SDN 100 further includes a controller pool 106 (also referred to as a control plane) including a plurality of controllers, such as a controller 108A, a controller 108B and a controller 108C. Each controller is connected to one or more routers, for example, the controller 108A is connected to a router 114A via a connection 112A and to a router 114B via a connection 112C. The controller 108B is connected to the router 114A via a connection 112B, to the router 114B via a connection 112D, and to a router 114C via a connection 112E. The controller 108C is connected to the router 114C via a connection 112F. The NMS 102 pushes policy in the network by pushing the policy to the controllers which, in turn, pushes the policy to the routers. However, there may arise a situation in which a controller loses its connectivity with the NMS 102.
FIG. 2 (prior art) indicates a scenario 200 in which the controller 108C has a broken connection 202 with the NMS 102. The NMS 102 pushes a new policy (shown via 204) to the controllers. All controllers except the controller 108C receive the new policy. This results in the controller pool 106 going out of sync and hence, no longer behaving as a single redundant control plane across internet protocol (IP) fabric. In light of this, it becomes very difficult to predict network/routing behaviour in the network.
FIG. 3 (prior art) indicates a solution 300 in which the NMS 102 blocks push of the new policy to the network, as shown by 302, till connectivity to all controllers in the controller pool 106 is restored. However, such a solution stops critical policy changes that may be needed urgently in the network. In addition, the solution stops pushing the new policy change to controllers that did not lose the connectivity. Further, the solution is prone to having similar issue, i.e. loss of connectivity with the controller 108C, again while the push of new policy is in process.
FIG. 4 (prior art) indicates a solution 400 in which the NMS 102 pushes the new policy to the network, as shown by 204 and simultaneously informs the management software 104 that the controller 108C has lost connectivity. The management software 104 then removes name of the controller 108C from a list of valid controllers. The list of valid controllers include controllers with which routers can establish connection. However, such a solution causes exclusion of the controller 108C from the list of valid controllers. In addition, the solution causes the controller 108C to break connections with connected routers and to re-establish those connections later on when the connection of the controller 108C with the NMS 102 is re-established. Further, the solution raises a requirement of establishing a signaling mechanism between the NMS 102 and the management software 104.
Therefore, there is a need for a method and a system for assigning an identifier to a policy and using that for synchronizing policy in the control plane.